ATM is a packet-switching technology that uses fixed-size packets, referred to as cells, to carry the traffic in a network. The ATM standard allows transmission of intermixed audio, video, and data over high-speed links. As well as being used in wide-area networks, the ATM standard can be used for local-area networks to support multimedia applications.
The unit of transmission used in the ATM standard is a cell. As shown in FIG. 1, an ATM cell 100 contains 53 bytes of information and has a five-byte header field 102 and a 48-byte payload field 104 carrying data. Header field 102 contains a Virtual Path Identifier (VPI) 106 and a Virtual Channel Identifier (VCI) 108 which are used for switching cell 100 through an ATM network. ATM header field 102 uniquely determines parameters associated with a given connection. Within an end user interface such as a computer, multiple connections can be going on at the same time.
Within a switch, each ATM cell is switched based on the information contained in its header; more specifically based on its VPI and VCI as shown in FIG. 1. A combination of VCI and VPI bits are used to index lookup tables that contain the switching information.
FIG. 2 illustrates the relationship between a physical transmission circuit 200 and a Virtual Path (VP) 202 and a Virtual Channel (VC) 204. Physical circuit 200 supports one or more virtual paths 202. Virtual path 202 may support one or more virtual channels 204. Thus, multiple virtual channels can be trunked over a single virtual path 202. ATM switching and multiplexing operate at either the virtual path or virtual channel level.
ADSL Customer Premises Equipment is usually configured with one Permanent Virtual Circuit (PVC) over which PPP or bridged request for comments (RFC) 1483 protocol traffic is supported. The RFC 1483 protocol is dated July 1993 published by Telecom Finland. In a PVC network, such as ATM, when a circuit is established, the route is chosen from source to destination, and all switches (e.g. routers) along the way may take entries so that they can switch any cells on that virtual circuit. When a cell comes along, a switch inspects the cell's header to find out which virtual circuit it belongs to. Then it looks up that virtual circuit in its tables to determine which output communication line to direct cell to. Therefore, there is an agreement between a customer and a service provider that the switches will always hold table entries for a particular destination, even if there has been no traffic for months.
FIG. 3 illustrates ATM cell switching using VPI and VCI values. Switch 300 maps VPIs and VCIs to different VPIs and VCIs at a connecting point 302. The network therefore ties together the VPIs and VCIs used on a link 304 within a physical transmission path 306 to deliver an end-to-end connection to end points 308.
In an end-user network such as the one illustrated in FIG. 4, a CPE device 400 communicates with a remote Digital Subscriber Line Access Multiplexer (DSLAM) 402 through a transmission path 404 having a PVC defined by a VPI and a VCI. DSLAM 402 communicates with an aggregator 418 connected to the Internet 420. CPE device 400 typically comprises of an ATM interface 406 and a LAN interface 408 connected to a network of PCs 410 through an Ethernet 412. Although CPE device 400 can have ATM interface 406 dynamically configured with IPCP address negotiation and DHCP client support that belong to layer 3 of a DSL protocol stack as shown in FIG. 5, the ATM PVC still needs to be pre-configured with a VPI and a VCI. A service provider deploying its CPE device actually knows the VPI and VCI for the PVC. However, a customer replacing, for example, a bridge with a router, may not know the VPI and VCI of the PVC that he or she is using. A second problem arises when CPE device 400 must determine a type of encapsulation, e.g. PPP over ATM software interface 414 or RFC 1483 bridge 416.
A need therefore exists for a method and a device that enable a CPE device to automatically configure its PVC and then link it to an interface such as PPP or RFC bridging so that both layer 2 (ATM PVC) and layer 3 (DHCP or IPCP) auto-configuration is achieved. Thus, a customer who buys the CPE device would not need to contact the service provider to find out about the VPI and VPC for the PVC. If the service provider sends RFC 1483 bridged traffic or PPP traffic (assuming that CHAP or PAP is not used), the customer would just need to plug the CPE device in and allow it to auto-configure itself.